@cline/shared 0.0.60 → 0.0.62-nightly.1784171655
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/agents/types.d.ts +5 -0
- package/dist/hub.d.ts +1 -1
- package/dist/index.browser.d.ts +6 -4
- package/dist/index.browser.js +33 -15
- package/dist/index.d.ts +6 -4
- package/dist/index.js +78 -60
- package/dist/llms/requests.d.ts +0 -20
- package/dist/llms/tokens.d.ts +10 -0
- package/dist/parse/jwt.d.ts +1 -0
- package/dist/prompt/cline.d.ts +19 -0
- package/dist/prompt/format.d.ts +17 -0
- package/package.json +1 -1
package/dist/llms/requests.d.ts
CHANGED
|
@@ -1,21 +1 @@
|
|
|
1
|
-
import type { ClientName } from "../extensions/context";
|
|
2
|
-
export declare const DEFAULT_REQUEST_HEADERS: Record<string, string>;
|
|
3
|
-
export interface ClineClientRequestHeadersInput {
|
|
4
|
-
providerId: string;
|
|
5
|
-
sessionId: string;
|
|
6
|
-
source?: string;
|
|
7
|
-
defaultSource: string;
|
|
8
|
-
clientName?: ClientName;
|
|
9
|
-
clientVersion?: string;
|
|
10
|
-
clientVersionHeaderFallback?: string;
|
|
11
|
-
platform?: string;
|
|
12
|
-
platformVersion?: string;
|
|
13
|
-
isMultiRoot?: boolean;
|
|
14
|
-
coreVersion: string;
|
|
15
|
-
}
|
|
16
|
-
export declare function buildClineClientRequestHeaders(input: ClineClientRequestHeadersInput): Record<string, string> | undefined;
|
|
17
|
-
export interface MergeClineClientRequestHeadersInput extends ClineClientRequestHeadersInput {
|
|
18
|
-
headers: ReadonlyArray<Record<string, string> | undefined>;
|
|
19
|
-
}
|
|
20
|
-
export declare function mergeClineClientRequestHeaders(input: MergeClineClientRequestHeadersInput): Record<string, string> | undefined;
|
|
21
1
|
export declare function serializeAbortReason(reason: unknown): unknown;
|
package/dist/llms/tokens.d.ts
CHANGED
|
@@ -6,3 +6,13 @@
|
|
|
6
6
|
*/
|
|
7
7
|
export declare const CHARS_PER_TOKEN = 3;
|
|
8
8
|
export declare function estimateTokens(chars: number): number;
|
|
9
|
+
export interface TokenEstimatedRequest {
|
|
10
|
+
systemPrompt?: string;
|
|
11
|
+
messages: readonly unknown[];
|
|
12
|
+
tools?: readonly unknown[];
|
|
13
|
+
}
|
|
14
|
+
/**
|
|
15
|
+
* Estimate the complete provider request payload so request execution and
|
|
16
|
+
* pre-request policies use the same definition of input utilization.
|
|
17
|
+
*/
|
|
18
|
+
export declare function estimateRequestInputTokens(request: TokenEstimatedRequest): number;
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
export declare function decodeJwtPayload(token?: string): Record<string, unknown> | null;
|
package/dist/prompt/cline.d.ts
CHANGED
|
@@ -1,5 +1,24 @@
|
|
|
1
1
|
import type { WorkspaceContext } from "../extensions/context";
|
|
2
2
|
import type { WorkspaceInfo } from "../session/workspace";
|
|
3
|
+
/**
|
|
4
|
+
* Explains the <user_input mode="..."> wrapper and <mode_notice> elements the
|
|
5
|
+
* runtime stamps on user messages (prepareTurnInput / formatUserInputBlock).
|
|
6
|
+
* Every host that sends through the SDK runtime produces those tags, so every
|
|
7
|
+
* host's system prompt must explain them: without this section the model has
|
|
8
|
+
* no idea what the attribute means, and a mid-conversation mode switch is an
|
|
9
|
+
* invisible system-prompt swap it cannot diff. Included for BOTH modes, since
|
|
10
|
+
* after a switch the transcript still contains messages tagged with the other
|
|
11
|
+
* mode.
|
|
12
|
+
*/
|
|
13
|
+
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.";
|
|
14
|
+
/**
|
|
15
|
+
* Plan-mode behavioral contract, appended when the session mode is "plan".
|
|
16
|
+
* run_commands intentionally stays available in plan mode -- it is essential
|
|
17
|
+
* for read-only investigation -- so the contract must spell out that it is
|
|
18
|
+
* inspection-only there; the mitigation for plan-mode mutations is prompting
|
|
19
|
+
* plus mode-switch notices, not tool removal.
|
|
20
|
+
*/
|
|
21
|
+
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.). 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.";
|
|
3
22
|
export declare function processWorkspaceInfo(info: WorkspaceInfo): string;
|
|
4
23
|
/**
|
|
5
24
|
* Options for building the Cline system prompt.
|
package/dist/prompt/format.d.ts
CHANGED
|
@@ -15,6 +15,23 @@ export declare function parseUserInputMode(input?: string): "act" | "plan" | "yo
|
|
|
15
15
|
* display by stripModeNotices at display boundaries.
|
|
16
16
|
*/
|
|
17
17
|
export declare function formatModeSwitchNotice(from: "act" | "plan", to: "act" | "plan"): string;
|
|
18
|
+
export type ModeSwitchNotice = {
|
|
19
|
+
from: "act" | "plan";
|
|
20
|
+
to: "act" | "plan";
|
|
21
|
+
};
|
|
22
|
+
/**
|
|
23
|
+
* Tracks a user-initiated mode switch so the next user message can carry a
|
|
24
|
+
* <mode_notice> marking it. Only UI toggles should be recorded: the
|
|
25
|
+
* model-initiated switch_to_act_mode path already announces itself via the
|
|
26
|
+
* continuation prompt. A round trip (plan -> act -> plan before sending
|
|
27
|
+
* anything) cancels out, since the mode the model last saw never effectively
|
|
28
|
+
* changed.
|
|
29
|
+
*/
|
|
30
|
+
export declare function createModeSwitchNoticeTracker(): {
|
|
31
|
+
record(from: "act" | "plan", to: "act" | "plan"): void;
|
|
32
|
+
consume(): ModeSwitchNotice | null;
|
|
33
|
+
};
|
|
34
|
+
export type ModeSwitchNoticeTracker = ReturnType<typeof createModeSwitchNoticeTracker>;
|
|
18
35
|
export type UserCommandEnvelope = {
|
|
19
36
|
slash: string;
|
|
20
37
|
content: string;
|