@cline/shared 0.0.85 → 0.0.86-nightly.1790389788

package/dist/llms/gateway.d.ts

@@ -87,7 +87,7 @@ export interface GatewayProviderMetadata {
      */
     imageTransport?: "openrouter";
     /** Provider-owned implementation used for the transcription operation. */
-    transcriptionTransport?: "openai-compatible" | "vercel-ai-gateway" | "elevenlabs";
+    transcriptionTransport?: "openai-native" | "openai-compatible" | "vercel-ai-gateway" | "elevenlabs";
     /**
      * Successful JSON responses are wrapped by the provider before reaching
      * the protocol adapter. `success-data` represents `{ success, data }`.

package/dist/llms/model-info.d.ts

@@ -118,8 +118,17 @@ export declare const ModelOperationSchema: z.ZodEnum<{
     "speech-generation": "speech-generation";
     "video-generation": "video-generation";
     transcription: "transcription";
+    realtime: "realtime";
 }>;
 export type ModelOperation = z.infer<typeof ModelOperationSchema>;
+/** Voice input requires exactly audio input and text output. Model names and
+ * operation labels cannot widen this to a multimodal realtime session. */
+export declare function isTranscriptionModel(model: {
+    modalities?: {
+        input?: readonly string[];
+        output?: readonly string[];
+    };
+}): boolean;
 export type ChatCompatibleModelDescriptor = {
     readonly operation?: ModelOperation;
     readonly modalities?: ChatModelModalities;
@@ -216,6 +225,7 @@ export declare const ModelInfoSchema: z.ZodObject<{
         "speech-generation": "speech-generation";
         "video-generation": "video-generation";
         transcription: "transcription";
+        realtime: "realtime";
     }>>;
     operationModes: z.ZodOptional<z.ZodArray<z.ZodEnum<{
         streaming: "streaming";

package/dist/llms/transcription.d.ts

@@ -0,0 +1,13 @@
+/** Short-lived browser credentials and the audio contract for a voice session. */
+export type StreamingAudioTranscriptionSession = {
+    token: string;
+    url: string;
+    sampleRate: number;
+    expiresAt?: number;
+} & ({
+    transport: "vercel-ai-gateway" | "openai-native";
+    modelId: string;
+    baseUrl: string;
+} | {
+    transport: "elevenlabs";
+});

package/dist/parse/path.d.ts

@@ -0,0 +1,14 @@
+/**
+ * Rewrite the current platform's path separator to `/`.
+ *
+ * Use it wherever a path leaves the filesystem layer for presentation, storage
+ * or comparison: mention pickers, task history shared across OSes, plugin
+ * manifests, dedupe keys. It splits on `path.sep` only, so on POSIX a literal
+ * backslash in a filename is left alone (`foo\bar.txt` stays `foo\bar.txt`),
+ * while on Windows `src\main.ts` becomes `src/main.ts`.
+ *
+ * This is deliberately not `replace(/\\/g, "/")`: that variant corrupts POSIX
+ * filenames containing backslashes. Reach for it only when the input is
+ * user-typed and may carry Windows separators on any OS.
+ */
+export declare function toPosixSeparators(p: string): string;

package/dist/prompt/cline.d.ts

@@ -3,12 +3,9 @@ import type { WorkspaceInfo } from "../session/workspace";
 /**
  * Explains the <user_input mode="..."> wrapper and <mode_notice> elements the
  * runtime stamps on user messages (prepareTurnInput / formatUserInputBlock).
- * Every host that sends through the SDK runtime produces those tags, so every
- * host's system prompt must explain them: without this section the model has
- * no idea what the attribute means, and a mid-conversation mode switch is an
- * invisible system-prompt swap it cannot diff. Included for BOTH modes, since
- * after a switch the transcript still contains messages tagged with the other
- * mode.
+ * Included in plan and act prompts so the model can interpret mode switches
+ * and earlier messages tagged with the other mode. YOLO prompts omit these
+ * instructions because they do not use the plan/act workflow.
  */
 export declare const MODE_TAG_INSTRUCTIONS = "# Plan / Act Modes\n\nUser messages arrive wrapped in a <user_input mode=\"...\"> tag. The mode attribute is the interaction mode the user was in when they sent that message: \"plan\" means plan-mode constraints applied (explore, analyze, and align on a plan -- no edits or state-changing commands), while \"act\" (or \"yolo\") means implementation was allowed. If the mode attribute changes between messages, the user switched modes -- the newest message's mode is what governs right now, regardless of what earlier messages allowed. A <mode_notice> block inside a message marks exactly when such a switch happened.";
 export declare const PLAN_MODE_INSTRUCTIONS = "# Plan Mode\n\nYou are in Plan mode. Your role is to explore, analyze, and plan -- not to execute.\n\n- Read files, search the codebase, and gather context to understand the problem\n- Ask clarifying questions when requirements are ambiguous\n- Present your plan as a structured outline with clear steps\n- Explain tradeoffs between different approaches when they exist\n- Do NOT edit files, write code, run destructive commands, or make any changes\n- Do NOT implement anything -- focus on understanding and alignment first\n\nThe run_commands tool remains available in plan mode strictly for read-only inspection -- listing files, searching (grep), reading configs, inspecting git history and diffs, checking tool versions, and the like. Never use it to change anything: no creating, modifying, or deleting files, no writing scripts that make changes, and no state-changing commands (installs, migrations, database or schema changes, container commands that mutate state, etc.). File-editing commands (rm/mv/cp, in-place edits like sed -i, output redirection to files outside /tmp, git commands that change the working tree, package installs) are hard-blocked in plan mode: they are not executed and return a tool error instead, so do not attempt them. If the task requires a mutation, put it in the plan; it happens only after the user switches to act mode.\n\nOnce the user has reviewed your plan and explicitly approved it in a follow-up message, use the switch_to_act_mode tool to switch to act mode and begin implementation. Calling switch_to_act_mode immediately starts execution, so never call it in the same turn you present a plan and never treat the original task request as approval -- end your turn after presenting the plan and wait for the user's response.";

package/dist/prompt/system/yolo.d.ts

@@ -1 +1 @@
-export declare const CLINE_SYSTEM_PROMPT_YOLO_MODE = "You are Cline, a careful and helpful coding agent that works in the background.\nYou are tasked to solve an issue reported by the user who you cannot communicate with directly.\nYour goal is to utilize the tools at your disposal to investigate and answer the question according to user's instructions with the aim to verify that the issue is resolved.\n\nRULES:\n- Always match output format exactly as shown in examples or existing files.\n- Use only libraries and frameworks that are confirmed and compatible to be in use in the current codebase.\n- Provide complete and functional code without omissions or placeholders.\n- Always show your planning process without repeating yourself before executing any task. This will help ensure that you have a clear understanding of the requirements and that your approach aligns with the user's request.\n- Always use absolute paths when referring to files.\n- You can call multiple tools in a single response. Before using tools, identify every independent read, search, command, or edit needed for the next step and emit all of those tool calls now, either as multiple tool calls or as one batched input for tools that accept arrays. Do not wait for one independent result before requesting another. Do not split independent reads, searches, checks, or edits across separate turns.\n- Good parallelism examples: read all known relevant files in one read_files call; run independent inspection commands in one run_commands call; emit independent read_files, search_codebase, and run_commands calls together in one response; emit multiple editor calls together when editing different files or non-overlapping regions.\n- Always verify the files you have edited or created at the end of the task to ensure they are completed and working as expected.\n\nEnvironment you are running in:\n<env>\n1. Platform: {{PLATFORM_NAME}}\n2. Date: {{CURRENT_DATE}}\n3. IDE: {{IDE_NAME}}\n4. Working Directory: {{CWD}}\n</env>\n\nIMPORTANT:\n- When the user describes a bug, unexpected behavior, or provides a bug report, your primary goal is to produce a correct fix in the source code that resolves the issue.\n- A correct fix means the underlying behavior is fixed \u2014 not just the symptoms addressed superficially.\n- Verify by execution, never by assumption. Before considering any task done, gather concrete evidence from your own tool output that every requirement is satisfied:\n    - If a test suite, tests, or assertions are provided or referenced, run them and confirm they pass. If they fail, analyze the failures, revise, and re-run until they pass.\n    - If no tests are provided, construct your own verification: actually run the program, script, or command you produced; confirm every required output file exists at the exact path requested; and confirm its contents match the expected format, data types, and values described in the task. Read the output back to confirm.\n- Treat \"this should work\", \"assume it works\", or \"probably correct\" as a signal that you have NOT verified yet \u2014 go run the check instead of finishing.\n- Do not consider the task complete until you have observed evidence that all stated requirements are met.\n- Always includes tool calls in your response until the task is completed. You should only end the task when all the requirements are met by calling the 'submit_and_exit' tool.\n- When you call 'submit_and_exit', set 'verified' to true only if your tool output shows the requirements are met; otherwise set it to false.\n- Response without the submit_and_exit tool call will considered not completed and the task will continue.\n{{CLINE_RULES}}\n{{CLINE_METADATA}}";
+export declare const CLINE_SYSTEM_PROMPT_YOLO_MODE = "You are Cline, a careful and helpful coding agent that works in the background.\nYou are tasked to solve an issue reported by the user who you cannot communicate with directly.\nYour goal is to utilize the tools at your disposal to investigate and answer the question according to user's instructions with the aim to verify that the issue is resolved.\n\nRULES:\n- Always match output format exactly as shown in examples or existing files.\n- Use only libraries and frameworks that are confirmed and compatible to be in use in the current codebase.\n- Provide complete and functional code without omissions or placeholders.\n- During thinking stage, show your planning process. Keep the plan to one short paragraph.\n- Be proactive and avoid overthinking. Once the next action is clear, execute it. Do not seek perfect certainty, repeatedly compare alternatives, or revisit settled decisions without new evidence. Use focused tool calls to resolve uncertainty.\n- If repeated fixes fail without new evidence, stop making similar edits. Test your assumptions with a focused check or minimal reproduction, then adjust your approach based on the result.\n- Put complete code, commands, and edit payloads in the tool arguments. Do not draft them in full in your plan if you can execute them directly.\n- Provide text response when it adds value: a brief plan summary for multi-step work, a meaningful progress update, concise task notes, a blocker, or the final result. Routine tool calls need no text preamble. Keep plan summaries and progress updates to one short paragraph, reporting decisions and new evidence rather than internal deliberation.\n- Keep task notes focused on confirmed facts, decisions, and remaining work. Update existing notes when possible instead of repeating the task history.\n- Always use absolute paths when referring to files.\n- You can call multiple tools in a single response. Before using tools, identify every independent read, search, command, or edit needed for the next step and emit all of those tool calls now, either as multiple tool calls or as one batched input for tools that accept arrays. Do not wait for one independent result before requesting another. Do not split independent reads, searches, checks, or edits across separate turns.\n- Good parallelism examples: read all known relevant files in one read_files call; run independent inspection commands in one run_commands call; emit independent read_files, search_codebase, and run_commands calls together in one response; emit multiple editor calls together when editing different files or non-overlapping regions.\n- Always verify the files you have edited or created at the end of the task to ensure they are completed and working as expected.\n\nEnvironment you are running in:\n<env>\n1. Platform: {{PLATFORM_NAME}}\n2. Date: {{CURRENT_DATE}}\n3. IDE: {{IDE_NAME}}\n4. Working Directory: {{CWD}}\n</env>\n\nIMPORTANT:\n- When the user describes a bug, unexpected behavior, or provides a bug report, your primary goal is to produce a correct fix in the source code that resolves the issue.\n- A correct fix means the underlying behavior is fixed \u2014 not just the symptoms addressed superficially.\n- Verify by execution, never by assumption. Before considering any task done, gather concrete evidence from your own tool output that every requirement is satisfied:\n    - If a test suite, tests, or assertions are provided or referenced, run them and confirm they pass. If they fail, analyze the failures, revise, and re-run until they pass.\n    - If no tests are provided, construct your own verification: actually run the program, script, or command you produced; confirm every required output file exists at the exact path requested; and confirm its contents match the expected format, data types, and values described in the task. Read the output back to confirm.\n- Treat \"this should work\", \"assume it works\", or \"probably correct\" as a signal that you have NOT verified yet \u2014 go run the check instead of finishing.\n- Do not consider the task complete until you have observed evidence that all stated requirements are met.\n- Always includes tool calls in your response until the task is completed. You should only end the task when all the requirements are met by calling the 'submit_and_exit' tool.\n- When you call 'submit_and_exit', set 'verified' to true only if your tool output shows the requirements are met; otherwise set it to false.\n- Response without the submit_and_exit tool call will considered not completed and the task will continue.\n{{CLINE_RULES}}\n{{CLINE_METADATA}}";

package/dist/runtime/bun-embedded-path.d.ts

@@ -0,0 +1,6 @@
+/**
+ * Whether a module path points into a compiled Bun executable's embedded
+ * virtual filesystem: `/$bunfs/root/...` on POSIX, `B:\~BUN\root\...` on
+ * Windows.
+ */
+export declare function isBunEmbeddedModulePath(modulePath: string | undefined): boolean;

package/dist/runtime/loopback-proxy-bypass.d.ts

@@ -0,0 +1,16 @@
+/**
+ * `NO_PROXY` matching in Bun (and curl) is literal per host, so every loopback
+ * spelling must be listed.
+ */
+export declare const LOOPBACK_NO_PROXY_HOSTS: readonly ["localhost", "127.0.0.1", "::1", "[::1]"];
+/**
+ * Exempt loopback traffic from proxy environment variables.
+ *
+ * Bun's `fetch` honors `HTTP_PROXY`/`HTTPS_PROXY` with no built-in localhost
+ * bypass, and a per-request `proxy` option does not override the environment,
+ * so a system proxy (Clash, v2ray, corporate setups) swallows every local hub
+ * probe and a healthy hub looks unreachable (cline/cline#14265, #14292).
+ * `NO_PROXY` is the only lever: append the loopback spellings whenever a proxy
+ * variable is set. Idempotent; spawned children inherit it.
+ */
+export declare function ensureLoopbackProxyBypass(env?: Record<string, string | undefined>): void;

package/dist/services/telemetry.d.ts

@@ -38,6 +38,7 @@ export declare const TASK_PROVIDER_STREAM_STARTED_EVENT = "task.provider_stream_
 export declare const TASK_FIRST_CHUNK_RECEIVED_EVENT = "task.first_chunk_received";
 export declare const TASK_PROVIDER_STREAM_FAILED_EVENT = "task.provider_stream_failed";
 export declare const TASK_CANCELLED_EVENT = "task.cancelled";
+export declare const TASK_MAX_TOKENS_RECOVERY_EVENT = "task.max_tokens_recovery";
 export interface CaptureTaskLifecycleEventInput {
     event: string;
     sessionId?: string;

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@cline/shared",
-	"version": "0.0.85",
+	"version": "0.0.86-nightly.1790389788",
 	"description": "Shared utilities, types, and schemas for Cline packages",
 	"repository": {
 		"type": "git",